IP Multimedia (IPMM) services provide a dynamic combination of voice, video, messaging, data, etc, within the same session. By growing the numbers of basic applications and the media which it is possible to combine, the number of services offered to the end users will grow, and the inter-personal communication experience will be enriched. This will lead to a new generation of personalised, rich multimedia communication services, including so-called “combinational IP Multimedia” services.
IP Multimedia Subsystem (IMS) is the technology defined by the Third Generation Partnership Project (3GPP) to provide IP Multimedia services over mobile communication networks. IMS provides key features to enrich the end-user person-to-person communication experience through the integration and interaction of services. IMS allows new rich person-to-person (client-to-client) as well as person-to-content (client-to-server) communications over an IP-based network. The IMS makes use of the Session Initiation Protocol (SIP) to set up and control calls or sessions between user terminals (or user terminals and application servers). The Session Description Protocol (SDP), carried by SIP signalling, is used to describe and negotiate the media components of the session. Whilst SIP was created as a user-to-user protocol, IMS allows operators and service providers to control user access to services and to charge users accordingly. Other protocols are used for media transmission and control, such as Real-time Transport Protocol and Real-time Transport Control Protocol (RTP/RTCP),
Existing cellular network deployments are dominated by the 2G and 3G standards. The process of rolling out so-called 4G networks has just begun, and it will be many years before 4G network coverage is sufficient to allow 2G and 3G networks to be withdrawn completely. A fundamental requirement for real-time service provision is the seamless handover of services for subscribers roaming across cell boundaries of the radio access network (RAN). Given the ongoing co-existence of 2G, 3G and 4G networks, it is particularly desirable to allow for the handover of real-time service connections such as voice calls between the different radio access technologies.
Considering further the 4G technology, this is being specified under the name LTE (Long Term Evolution) and SAE (System Architecture Evolution) in 3GPP. The LTE radio access network technology implements only a packet switched access, in contrast to 2G and 3G (using GERAN and UTRAN radio access network technologies respectively) which provide for both packet switched and circuit switched access. In 2G and 3G networks, packet switched connections are used to carry data whilst circuit switched connections are used for real-time services such as voice calls. In 4G networks, all services will be carried via packet switched connections. In the case of a voice call initiated when a user is attached to a LTE radio access network (termed Enhanced UTRAN or E-UTRAN), that call will of course make use of a packet switched connection. If it is necessary for the call to be transferred to a 2G or 3G radio access network, e.g. because the user roams out of the coverage area of the E-UTRAN and into that of a GERAN or UTRAN network, the call must be switched from a packet switched (PS) access to a circuit switched (CS) access. Of course, the process for implementing the handover must be seamless such that little or no disruption of the call is perceived by the user. An appropriate access handover mechanism is also required in the case of the handover of a call from a PS access using a 3G UTRAN (HSPA) access network to a CS call using either 3G UTRAN access or 2G GSM access.
FIG. 1 illustrates schematically a scenario in which a user terminal (or User Equipment, UE, according to 3G terminology) initiates a voice call using a LTE radio access network and is subsequently handed over to a GSM/Edge Radio Access Network (GERAN). The call is established using the IMS network described above and which provides a common service control network for the PS and CS domains provided through the LTE, UTRAN, or GERAN radio accesses. In particular, the IMS includes a Multimedia Telephony (MMTel) Application Server which implements service logic for establishing and controlling voice calls. In order to implement the access handover, media control must be transferred from the Evolved Packet Core (EPC) network of the 4G domain to an allocated Mobile Switching Centre (MSC) within the 2G domain. Other components illustrated in FIG. 1 are a Mobile Switching Centre Server (MSS) which has support for the GSM access network, an enhanced Node B (eNodeB) which provides inter alia control of radio access within the LTE RAN, a Serving/PDN gateway (S/P-GW), a Mobility Management Entity (MME) (both the S/P-GW and the MME reside within the EPC), and a Home Subscriber Server that resides within a subscriber's home network.
The S/P-GW sits in the user plane where it forwards and routes packets to and from the eNodeB and the PDN GW. The S/P-GW also serves as the local mobility anchor for inter-eNodeB handovers and roaming between two 3GPP systems. The PDN GW (not shown in FIG. 1) acts as the interface between the radio network and the Packet Data Networks (PDNs), such as the Internet or SIP-based IP Multimedia Subsystem (IMS) networks (fixed and mobile). The PDN GW is the mobility anchor point for intra-3GPP access system mobility and for mobility between 3GPP access systems and non-3GPP access systems.
Interworking solutions for IMS Centralized Services (ICS) as specified in 3GPP TS 23.292, “IP Multimedia Subsystem (IMS) centralized services; Stage 2”, allows IMS sessions using CS bearers to be treated as standard IMS sessions, which is required for the purpose of IMS Service Continuity. ICS defines signalling mechanisms between the UE and IMS for transport of information to centralise the service in the IMS, and TS 23.237 “IP Multimedia Subsystem (IMS) Service Continuity” defines the additional procedures needed for service continuity when using CS access for media transport. Within the context of TS 23.292 and TS 23.237, the further 3GPP document TS 23.216: “Single Radio Voice Call Continuity (SRVCC); Stage 2”, describes a mechanism for handing over a voice call from a PS to a CS access. With reference to FIG. 1, this relies upon ICS and Service Continuity functionality that is implemented in the Service Centralisation and Continuity Application Server (SCC AS) within the IMS (shown co-located with the MMTel AS in FIG. 1). Whilst effective, the mechanism described in TS 23.216 (identified as Rel-9) involves a relatively long path for handover control signalling given that the SCC AS is located in a user's home network and the signalling may have to pass through an IMS network associated with a visited network (in the case of a roaming subscriber where the serving network is not the home network). Handovers may be delayed as a result, possibly giving rise to interruptions in voice calls. SRVCC is applicable to handover to a CS access from a PS access where that PS access is provided by either of a LTE access or a UTRAN (HSPA) access.
It has been recognised that such a long path for access handover related signalling is undesirable. This problem is addressed in TS 23.237, “IP Multimedia Subsystem (IMS) Service Continuity”, which proposes introducing the architecture illustrated in FIG. 2. An Access Transfer Control Function (ATCF) is included in the serving (e.g. visited) IMS network. This approach is referred to as Rel-10. According to Rel-10, the ATCF acts as a media gateway controller for an Access Transfer Gateway (ATGW) that is also present in the serving IMS network. The ATGW acts as an anchor for the IMS media traffic to allow media traffic to be switched quickly from the PS access network to the CS access network via the MSC. Additional functions of IMS Service Continuity are provided by the ATCF/ATGW in the serving (visited if roaming) network. In particular, responsibility for managing radio access handovers is delegated from the SCC AS to the ATGW. Within the CS core network, a SRVCC function is introduced into one of the network MSCs. This may or may not be the same MSC as the Target MSC for the handover.
When the UE performs IMS registration, a decision is made (by the P-CSCF) as to whether or not to include the ATCF in the path. If the ATCF is included, the ATCF reports a Session Transfer Number Single Radio (STN-SR) to the SCC AS in the home IMS network. This STN-SR is recorded by the SCC-AS in the HSS in respect of the ongoing IMS session. The STN-SR points uniquely to the ATCF. When the UE is either initiating or receiving an incoming call, the ATCF makes a decision concerning whether or not to anchor the media in the controlled ATGW. If the media is anchored at the ATGW, then when an access handover takes place, the redirection of media to the new access will be carried out locally in the serving (e.g. visited) network. The anchored media in the ATGW is redirected to the CS side instead of the PS side. This procedure is illustrated further in FIG. 3 which shows the signalling and media paths before and after handover.
FIG. 4 shows the Rel-10 IMS registration procedure in more detail. The figure illustrates in particular that the ATCF in the serving network includes its STN-SR in the IMS Register message that it forwards to the home network of UE-1 at registration of that subscriber. This STN-SR is recorded by the SCC-AS in the HSS in respect of the ongoing IMS session, and the HSS further updates the MME(LTE)/SGSN(UTRAN HSPA) with the changed user information (STN-SR) by sending an Insert Subscribe Data to the MME/SGSN, including the STN-SR. By so doing, the MME/SGSN will have the latest STN-SR pointing to the ATCF to be used at handover. It is noted that, if the ATCF decides not to be included (or no ATCF is present), no STN-SR will be sent to the SCC AS. The SCC AS will then update the HSS with the STN-SR pointing to the SCC AS, and the SRVCC procedures will fall back to the Rel-9 SRVCC procedures.
Referring now to FIG. 5, this figure illustrates an originating (side) procedure that occurs following IMS registration of UE-1 according to the procedure of FIG. 4. Relevant to this discussion are the media anchor decision made by the originating side ATCF upon receipt of the SIP Invite originating from UE-1 (and a possible Late Media Anchor decision made by the same node), and the sending of Transfer information from the SCC AS in the home network to the ATCF for storage by the ATCF for the duration of the call. The Transfer information sent to and stored by the ATCF includes the C-MSISDN and the ATU-STI. The C-MSISDN provides information that helps the ATCF to correlate the IMS session over the PS access with the INVITE sent from the MSC Server during a session transfer, whilst the ATU-STI provides routing information to the SCC AS (in effect, the ATU-STI is an address of the SCC AS). FIG. 6 illustrates a corresponding terminating (side) procedure that again assumes that the relevant subscriber, that is UE-1, has performed IMS registration according to the procedure of FIG. 4, prior to UE-2 sending a SIP Invite addressed to UE-1.
Referring now to FIG. 7, this figure illustrates the access transfer procedures when the UE has its media moved from the PS access to the CS access. The UE and the network detect that SRVCC needs to be applied (e.g., the UE is losing LTE radio coverage). This then triggers the MME/SGSN to inform the MSC Server to initiate the access transfer procedures, notifying the MSC Server of the STN-SR previously provided to the MME/SGSN. The MSC Server sends an INVITE to the ATCF using the received STN-SR. The INVITE includes also the C-MSISDN. The INVITE is routed to the ATCF, which can then correlate the INVITE with the ongoing session that the user has on the PS access, using the C-MSISDN. The ATCF can then update the ATGW to move the media path from the PS to the CS access (i.e., send the media towards the MSC/MGW instead). The ATCF also informs the SCC AS about the access transfer, and additional mid call states may be transferred.
SRVCC enhancements as described in TS 23.237 (v10.3.0) require that a UE has only one IMS registration at a given time (S2-104384, 6.1.2). The reason for this is that the ATCF is selected when the UE registers with the IMS, with the STN-SR for the ATCF being provided to the MME/SGSN via the SCC AS. When SRVCC (PS to CS access handover) takes place, the SRVCC INVITE request (sent by the MSC Server in the CS access network) is routed to a single ATCF using the single known STN-SR, with the ATCF then transferring the most recently active speech session established in the E-UTRAN/UTRAN network. To select the session, the ATCF must be aware of all the speech sessions of the UE established in E-UTRAN/UTRAN network. However, 3GPP TS 24.229 allows a UE to make several IMS registrations even in LTE/GPRS network, for example to provide for failure handling. This capability should not be restricted by SRVCC. Currently, if multiple registrations were to be done (through different ATCFs), it is not clear what would happen as only one STN-SR can be provided to the HSS (and MME/SGSN). A problem to be addressed therefore is how to allow a UE to perform multiple IMS registrations while at the same time allowing for SRVCC access handovers.